5. Contingency Planning

Intent

Contingencies are deliberate, pre-decided responses to anticipated failure, change, or uncertainty. They preserve mission objectives when primary actions fail.

Contingency planning ensures mission execution can continue if:

A critical Assumption proves false
A planned TT cannot be executed
A technical or authority constraint prevents intended action
Environmental or adversary conditions change

NOTE: Initial contingencies are developed before ROC Drills and are validated, refined, or rejected through ROC execution.

5.1. Contingency Planning Principles

Purpose

Define how contingencies are derived and structured within the TMP.

Every unresolved Assumption that affects execution must have at least one contingency.
Every high-risk or high-impact TT must have a defined fallback.
Contingencies are not alternate plans - they are controlled deviations.
A contingency must:
- Have a clearly defined Trigger
- Describe the Impact to mission execution
- Provide a defined Response
- Identify who has decision authority to execute it
Contingencies must preserve:
- Mission alignment
- Authorities and constraints
- Acceptable Level of Risk (ALR)

5.2. Types of Contingencies

Assumption-Driven Contingencies
- Derived directly from unresolved or high-risk assumptions identified during Mission Analysis.
- Examples:
  - Access not granted as expected
  - Required log sources unavailable
  - ATC restrictions imposed
  - Intelligence support delayed
NOTE: If the assumption affects a TT, a backup TT must be defined.
Technical Failure Contingencies
- Triggered when execution fails despite correct planning.
- Examples:
  - Sensor deployment failure
  - Agent installation failure
  - Collection pipeline failure
  - System instability caused by CPT actions
Authority / Constraint Contingencies
- Triggered when execution is restricted due to legal, command, or mission partner constraints.
- Examples:
  - Blocking actions denied
  - Host quarantine not authorized
  - Credential creation restricted
  - Required escalation authority unavailable
Adversary-Driven Contingencies
- Triggered when adversary behavior materially changes mission conditions.
- Examples:
  - Active C2 detected during planning
  - Widespread lateral movement observed
  - Evidence of data exfiltration
  - ICS process manipulation detected
- These may require:
  - Phasing adjustment
  - Priority shift
  - Risk re-evaluation
  - Immediate escalation

5.3. Contingency Structure

All contingencies will be documented with the following elements:

TT-#.# / EVENT: Identifies the specific execution task or operational event the contingency supports
- TRIGGER: The clearly defined condition (time-based or condition-based) that activates the contingency
  - IMPACT: The operational effect on mission execution if the trigger condition occurs
  - RESPONSE: The action taken to preserve (or abort) mission execution
  - DECISION AUTHORITY (if required): Identifies who is authorized to execute the contingency if it exceeds normal LOE authority

NOTE: Contingencies must be tied to specific execution tasks or events.

Example

TT-1.8: Deploy host agents to DAL endpoints IAW 262COS-HA-SOP-002
- TRIGGER: Host agent causes system instability
  - IMPACT: System and MCA alerting degraded
  - RESPONSE: Uninstall host agent

5.4. Contingency Discipline Rules

Contingencies must not introduce new uncontrolled risk
Contingencies must not violate defined constraints or restraints
No "we will figure it out" responses
All contingencies must have:
- Clear ownership
- Clear trigger
- Clear response
After GICL, only risk-driven contingency additions are authorized
Contingencies must be executable without additional planning

NOTE: Contingencies are a control mechanism - not improvisation authority.

5.5. Contingency Development Process

During planning:

Identify high-risk TTs
Review unresolved assumptions
Identify single points of failure
Define:
- Trigger thresholds (time-based, condition-based, authority-based)
- Immediate response
- Required coordination
Validate:
- Does the contingency still support the TO?
- Does it remain within constraints and ALR?

NOTE: Contingencies must be validated during the ROC Drill.

5.6. EXAMPLE: Contingencies

tip

TT-1.3: Deploy a virtual DIP sensor within the 318 RANS DIP internal network
- TRIGGER: Virtual DIP cannot PXE boot after 2 hrs troubleshooting
  - IMPACT: Degraded network visibility (no Zeek, Suricata, Arkime)
  - RESPONSE: Install OS on virtual sensor via CPT ISO (coord 318 RANS)
- TRIGGER: Virtual DIP cannot interoperate with physical DIP after 4 hrs troubleshooting
  - IMPACT: Pre-built physical DIP unavailable
  - RESPONSE: Install virtual DIP with 262COS customization (coord 318 RANS + ShOC-N)

TT-1.5: Configure MIPs for operation and safe connectivity to the DAL
- TRIGGER: MIP OS inoperable after 30 min troubleshooting
  - IMPACT: Crew member cannot operate CVA/H
  - RESPONSE: Use backup MIP/drive and redeploy replacement

TT-1.8: Deploy host agents to DAL endpoints IAW 262COS-HA-SOP-002
- TRIGGER: Scripted agent deployment fails after 30 min
  - IMPACT: Deployment timeline increased
  - RESPONSE: Perform manual agent deployment
- TRIGGER: Endgame fails to install after 30 min
  - IMPACT: No MCA alerting; manual analysis required
  - RESPONSE: Use Auditbeat; if unavailable, use active Metasponse collections
- TRIGGER: Sysmon fails to install after 30 min
  - IMPACT: Detailed event logging degraded
  - RESPONSE: Use native Windows event logs
- TRIGGER: Winlogbeat fails to install after 30 min
  - IMPACT: Detailed logging degraded
  - RESPONSE: Use Endgame Stream; if unavailable, use active Metasponse collections
- TRIGGER: Auditbeat fails to install after 30 min
  - IMPACT: System/user/software audit logging unavailable
  - RESPONSE: Use Endgame Stream; if unavailable, use active Metasponse collections
- TRIGGER: Host agent causes system instability
  - IMPACT: System and MCA alerting degraded
  - RESPONSE: Uninstall host agent

TT-2.1: Create administrator/root user accounts restricted for CPT use within the DAL
- TRIGGER: New CPT accounts cannot be created after 30 min
  - IMPACT: No dedicated privileged accounts
  - RESPONSE: Use existing administrator accounts

TT-3.2: Develop ICS environment specific signatures for detecting critical ICS actions
- TRIGGER: ICS-specific signatures not developed after 2 hrs
  - IMPACT: ICS state changes not easily identified
  - RESPONSE: Analyze rogue communications to ICS assets

TT-4.6: When necessary, quarantine/isolate hosts compromised by MCA until positive control of the host assumed
- TRIGGER: Unable to quarantine host after 15 min
  - IMPACT: MCA continues operations
  - RESPONSE: Prioritize host clearing and/or host firewall blocks

TT-4.7: Assist local defenders in implementing network-based blocks to prevent MCA C2
- TRIGGER: Network blocks on malicious IPs/domains fail after 30 min
  - IMPACT: MCA C2 continues
  - RESPONSE: Terminate processes communicating with malicious IPs/domains

EMERGENCY
- TRIGGER: Emergency condition per 262COS-EP-SOP-001
  - IMPACT: Potential halt/degradation of sortie
  - RESPONSE: Execute emergency procedures IAW 262COS-EP-SOP-001

5.1. Contingency Planning Principles​

5.2. Types of Contingencies​

5.3. Contingency Structure​

5.4. Contingency Discipline Rules​

5.5. Contingency Development Process​

5.6. EXAMPLE: Contingencies​